FIG. 1 shows a known database system 100 having a communications multiplexor 103. The database system 100 is stored in memory 116 of a data processing system 114. Also stored in memory 116 is the UNIX operating system. Client connections 102 are handled by a communications multiplexor 103 which includes dispatcher processes 104, reply queues 106, request queues 108 and agent processes 110. The communications multiplexor 103 connects client connections 102 to a physical database 112. Each client connection may include a request for requesting data or information about the data stored in physical database 112. Dispatcher processes 104 includes dispatcher process ‘A’, dispatcher process ‘B’, and dispatcher process ‘C’. Agent processes 110 includes agent process ‘D’, agent process ‘E’, agent process ‘F’, agent process ‘G’, and agent process ‘H’. Each dispatcher process ‘A’, ‘B’, and ‘C’ handles a respective group of client connections 102 (that is, handles one or more client connections). For example, FIG. 1 shows that dispatcher processes ‘A’ and ‘B’ handle three client connections each, and dispatcher process ‘B’ handles one client connection. The dispatcher processes 104 listen for activity on client connections 102 that they respectively handle. When a specific dispatcher process, such as dispatcher process ‘A’, detects activity on a respective client connection, the specific dispatcher process reads the request from that active client connection, writes the request into shared memory, and writes the detected request into request queue 108. The purpose for writing the request to shared memory (which happens to cause a significant communications bottle neck problem) will be further explained as follows: the client has sent a request to the database system over the client connection. The dispatcher process will read this request from the client connection. The dispatcher process must pass that client request to the agent process using some mechanism or manner. A way to achieve this mechanism is to write the request into a memory location and then pass a pointer (that is, a reference) to that memory location containing the request to the agent process via the request queue. The agent process will then know which memory location to read or to examine in order to process the request. Since by default, however, memory in process-based operating systems is private to a given process, the dispatcher process must write this request into an area of shared memory (that is, memory that is shared by multiple processes) so that the agent process will be able to read and process that memory shared memory location. It is a disadvantage to have a multitude of processing reading contents stored in shared memory locations because this causes operation to significantly slow down.
Subsequently, an available agent process, such as agent process ‘E’, reads the request stored in the request queue 108, and performs the service requested in the request, such as obtaining information from the physical database 112. Then, the agent process ‘E’ writes a reply into shared memory and writes the reply into the reply queue 106 (for example, the reply is written to reply queue ‘J’) for subsequent handling by the dispatcher process ‘A’ (that is, the dispatcher process that owns the active client connection that supplied the original request). The reply is written to shared memory for the same reason as described above; it is desired to have the agent process write a reply to shared memory and then pass a reference to that memory to the dispatcher process, so that the dispatcher process can then write the reply from that shared memory location to the client connection. To do this once again it is desired to write the reply to memory that is accessible (that is, shared) by both the agent process and the dispatcher process.
The dispatcher process ‘A’ then reads the reply currently stored in the reply queue ‘J’, and writes that reply into the appropriate client connection that provided the original request. The most likely implementation of the known database system would involve the dispatcher process copying the request from the client connection to shared memory, and then passing a pointer (or a reference or a handle) to that shared memory through the request queue to an agent (to those skilled in the art, this could be referred to as ‘passing the request’). The request queue itself could have multiple incarnations. It could be a linked list of pointers in shared memory, or it could also be one of the operating system inter-process communication mechanisms such as a socket or a pipe. Disadvantageously, when a dispatcher process handles a multitude of client connections, the dispatcher process becomes a significant bottle neck in the communications mutliplexor 103 because the dispatcher process reads and writes a multitude of requests (that came from the client connections) to locations in shared memory.
Known database system 100 does not pass client connections between dispatcher processes. Each client connection is kept with a respective dispatcher process for the lifetime of the client connection. Also, each dispatcher process performs all communication tasks with the client connections. On one hand, the operation of a communications multiplexor 103 is simple. On the other hand, the dispatcher processes 104 become a communications bottleneck in which client connections that have become newly active with a respective dispatcher process may have to wait for other client connection communications to be completely serviced before those newly active client connections may become serviced by an available dispatcher process. Client connections that become active on a single dispatcher process may have to wait for that dispatcher process to become available for passing requests to the request queue. A dispatcher process may be tied up because it is currently performing other communications for other client connections that are current being handled (hence the communications bottleneck occurs). Also, because a dispatcher process may be handling the communication connections for an active client connection, and the requests are being serviced by separate agent processes, the requests and replies must be passed between the dispatcher processes 104 and the agent processes 110 via shared memory. In general, the database system will use shared memory to store all the major shared data structures in the system (anything that can be accessed by dispatcher processes and agent processes). All this means is that the main data structures (such as the reply or request queues in this case) are stored in a shared place in memory where any process in the database system can access them. Also, shared memory is used extensively for communications between processes, in which one process writes information into a chunk of shared memory (or shared memory chunk) and another process once notified of the correct address of the memory can read those details. On database systems with a limited amount of shared memory, this situation may result in a scalability penalty which is generally inconvenient.
Communications multiplexor 103 includes request queues (comprised of reply queues 106 and request queues 108) for passing requests and replies between dispatcher processes 104 and agent processes 110. Use of these queues leads to two disadvantages. Firstly, on database systems that perform parallel execution of client requests, the single queue increasingly becomes a contention point as only one process may operate on it at a time. It is believed that the queue is more of a contention or bottleneck point in preventing agent processes from processing requests in parallel. Secondly, since any given agent process may serve any given client connection, this removes the ability to pool private resources associated with a given database 112 (for example, with a given set of agent processes). In UNIX operating systems having limits on the amount of shared memory and in which certain resources are kept private, this may result in a performance penalty.
Communications multiplexor 103 provides operation for handling a file table state that client connections may need to maintain besides the actual connection descriptor (that is, client connection descriptors). The connection descriptor refers to the file descriptor for the client connection, that is, the OS (operating system) handle to the client connection. No special mention of any such mechanism is made, and the most straightforward way of handling this with the communications multiplexor 103 may be to have those files open in the same dispatcher process as the client connection lives or continues to persist. Inconveniently, there may be a full scalability penalty for each of these files occupying the file table space of the dispatcher processes. Additionally, there may be performance penalties for the dispatcher processes performing any I/O (Input/Output) operations needed on these files.
Accordingly, a solution that addresses, at least in part, this and other shortcomings is desired.